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La presente invention concerne un procede de simulation de 
performances, et procedS de realisation duplications multiprocesseurs, et 
des dispositifs permettant de mettre en oeuvre lesdits proced^s. Elle 
s'applique notamment aux applications multiprocesseurs necessitant une 

5 forte puissance de calcul, telles que les traitements de signaux 
systematiques (TSS) des radars, les traitements d'images, ou les 
compressions de donnees temps reel. 

On appelle application multiprocesseur une application destinee a 
etre execute sur une architecture multiprocesseur. Une architecture 

10 comprend des Elements materiels (dits « hardware » dans la litterature 
anglo-saxonne) et des elements logiciels (dits « software » dans la litterature 
anglo-saxonne). Les elements materiels comprennent par exemple des 
processeurs, des memoires, des circuits specialises, et des bus de donnees. 
Les elements logiciels comprennent par exemple un jeu destructions de 

15 base mises a la disposition du programmeur, dit API (de I' expression anglo- 
saxonne « Application Programming Interface »), des programmes de 
communication bas niveau, et un ordonnanceur. Les Elements materiels 
d'une architecture s'appellent aussi des ressources. Les elements logiciels 
d'une architecture s'appellent aussi des services. 

20 Le placement est une etape intervenant lors de la realisation 

^'applications multiprocesseurs. II consiste a transformer une application 
decrite de maniere fonctionnelle en un ensemble de sous-applications 
destinies chacune a Tun des processeurs d'une architecture cible. Lors de 
I'etape de placement, on cherche a faire executer des calculs en parallele 

25 par plusieurs processeurs de I'architecture cible. Une premiere maniere 
d'executer des calculs en parallele, appelee parallelisme de tache, consiste a 
repartir des taches differentes sur plusieurs processeurs ou groupes de 
processeurs. Les differentes taches s'executent alors en meme temps sur 
des processeurs ou groupes de processeurs differents. Une seconde 

30 maniere d'executer des calculs en parallele, appelee parallelisme de 
donnees, consiste a repartir une meme tache sur plusieurs processeurs. 
Selon ce second mode de fonctionnement, dit SIMD ou SPMD (« Single 
Instruction Multiple Data » ou « Single Program Multiple Data »), plusieurs 
processeurs executent alors en meme temps et de facon synchronisee des 

35 calculs correspondant a une meme tache, mais sur des donnees differentes. 
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Le placement comprend generalement une etape appelee 
partitionnement, une etape appelee affectation et une etape appelee 
ordonnancement. Le partitionnement consiste, a partir d'une application 
decrite de maniere fonctionnelle, a decouper Tapplication en sous ensembles 
5 disjoints d'etapes de calculs elementaires (parallelisme de taches) appelees 
taches d'une part, et / ou a partager des blocs de donnees homogenes en 
blocs de donnees elementaires (parallelisme de donnees) d'autre part. 
L'affectation, connue sous le nom de « mapping » dans la litterature anglo- 
saxonne, consiste a allouer les taches elementaires et les blocs de donnees 

10 elementaires aux elements de Parchitecture tels que des processeurs pour 
des taches, et des memoires pour des blocs de donnees. L'ordonnancement 
consiste a determiner la chronologie d'execution des taches. [.'architecture 
multiprocesseurs choisie est souvent appelee architecture cible. L' application 
peut etre decrite de maniere fonctionnelle par un logiciel de haut niveau ou 

15 par une representation graphique ou DFG (de I'expression anglo-saxonne 
« Data Flow Graph »). Les taches peuvent etre decrites sous une forme 
manipulate par des outils de generation de code (compilateurs par 
exemple), ou sous forme de codes utilisables par des processeurs 
elementaires. 

20 Un bon placement permet d'assurer un bon rendement de 

I'architecture, c'est a dire tirer au mieux parti des possibilites (puissance de 
calcul, debits de communication) de ses ressources. Par consequent, un tel 
placement permet d'economiser des composants materiels dans 
1'architecture. Une architecture cible peut passer par exemple de 20 cartes 

25 electroniques a 10 cartes electroniques, grace a un meilleur placement d'une 
meme application. 

Or le travail de placement duplications sur des architectures 
cibles est complexe, et par consequent long et couteux. Ce travail est 
d'autant plus long et couteux que Ton recherche de hauts rendements 

30 d'execution. De plus, un placement efficace n'offre en general aucune 
souplesse. Si on souhaite ajouter des fonctionnalites a une application 
donnee ou changer d'architecture cible (appele « retrofit » dans la litterature 
anglo-saxonne), tout le travail de placement est a refaire. 

D'autres etapes peuvent intervenir lors de la realisation 

35 ^applications multiprocesseurs. On peut citer la simulation des 
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performances qui est necessaire pour apprecier le comportement en temps 
reel de I'application placee avant de I'executer sur I'architecture cible reelle. 
Cette simulation de performances depend de I'architecture cible d'une part, 
et du placement d'autre part. A chaque changement d'architecture, ces 
5 autres etapes sont a recommencer, ce qui est long et couteux. 

On utilise parfois des architectures possedant des services 
evolues pour faciliter la realisation d'applications multiprocesseurs. Ces 
services prennent a leur charge une partie des details relatifs notamment a la 
cohesion entre processeurs, qui sans cela doivent etre regies par le 
10 programmeur. La contrepartie est que de telles architectures sont complexes 
et utilisent beaucoup plus de ressources que les architectures classiques. De 
plus le comportement temps reel de telles architectures est moins previsible. 
Le rendement du placement, pouvant se mesurer par le nombre d'operations 
de calcul realisees par une ressource de I'architecture cible par rapport a sa 
15 capacite theorique, est plus difficile a maTtriser et souvent plus faible pour de 
telles architectures cibles. 

Une telle solution ne convient pas pour les applications 
necessitant une forte puissance de calcul, telles que les traitements de 
signaux systematiques (TSS) des radars, les traitements d'images, ou les 
20 compressions de donnees temps reel. Ces applications, du type traitement 
du signal systematique (TSS), necessitent des architectures de plus en plus 
volumineuses pour pouvoir etre executees en temps reel. Ces applications 
TSS necessitent un certain degre d'optimisation. 

Un but de I'invention est de pallier aux inconvenients precites et 
25 notamment de r^duire le temps n6cessaire a la realisation d'applications 
multiprocesseurs tout en optimisant le placement desdites applications d'une 
part, et de permettre de changer facilement d'architecture cible d'autre part. 

A cet effet I'invention concerne un procede de realisation d'une 
application multiprocesseur comprenant les etapes suivantes : 
30 (a) une etape (E1) de placement de I'application sur I'architecture cible, en 
utilisant une description (D1) fonctionnelle de ladite application d'une 
part, et la liste des ressources (A1) de I'architecture cible d'autre part, de 
maniere a produire un graphe (D2) de taches ; 
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(b) une etape (E2) de preparation d'une simulation pour produire un graphe 
(D3) de services, a partir d'un graphe (D2) de taches d'une part, et d'une 
liste de mecanismes et leurs definition (A2) d'autre part ; 

(c) une etape (E3) d'execution de la simulation, pour determiner les 
5 performances de I'application placee, a partir d'un modele 

comportemental (A3) de I'architecture cible d'une part, et du graphe (D3) 
de services d'autre part. 

L'invention concerne aussi le procede de simulation intervenant 
lors dans le procede de realisation d'application multiprocesseur, et les 
10 dispositifs permettant de mettre en oeuvre lesdits procedes. 

Uinvention a pour principaux avantages qu'elle permet de realiser 
une simulation comportementale dans laquelle I'heure simulee est 
incrementee de fagon a comcider exactement avec la fin d'execution d'un 
service, et dont la precision peut etre adaptee facilement a moindre cout en 
15 ne modifiant que les modeles comportementaux. 

D'autres caracteristiques et avantages de Pinvention apparaitront 
a I'aide de la description qui suit faite en regard de dessins annexes qui 
represented : 

• la figure 1, un exemple de realisation duplications multiprocesseurs 
20 selon l'invention sous la forme d'un schema synoptique ; 

• la figure 2, un exemple de placement sous la forme d'un schema 
synoptique ; 

• la figure 3, un exemple d'atelier de placement permettant de mettre en 
oeuvre le procede de realisation d'application illustre figure 1 ; 

25 • la figure 4, un exemple de modele comportemental utilise dans Tatelier de 
placement illustre figure 3 sous la forme d'un diagramme d'objets ; 

• la figure 5, un exemple d'objets utilises lors d'une simulation dans Tatelier 
de placement illustre figure 3, sous la forme d'un diagramme d'objets ; 

• la figure 6, un exemple de diagramme de classes correspondant aux 
30 ressources de I'architecture cible ; 

• la figure 7, un exemple de diagramme de classes correspondant a des 
m6canismes ; 

• la figure 8, un exemple d'objets utilises lors d'une etape de preparation de 
la simulation, sous la forme d'un diagramme d'objets ; 
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• les figures 9, 10, et 11, des exemples de classes correspondent a des 
taches, des mecanismes et des services ; 

• ia figure 12, un exemple de simulation. 

5 On se refere maintenant a la figure 1 sur laquelle est represents 

un exemple de realisation d'applications multiprocesseurs selon I'invention 
sous la forme d'un schema synoptique. On utilise generalement un atelier 
logiciel pour realisation les applications, multiprocesseurs. Un tel atelier peut 
comprendre un ou plusieurs programmes cooperant entre eux en 

10 echangeant des donnees a un format determine. L'utilisateur d'un tel atelier 
est appel6 un mappeur. Cet atelier depend de Tarchitecture cible sur laquelle 
('application est destinee a etre execute. 

L'application non placee D1 est decrite de maniere fonctionnelle, 
c'est a dire maniere independante de I'architecture. Cette description D1 de 

15 l'application peut comprendre des taches de calcul independantes de toute 
architecture. L'application peut etre une application de TSS par exemple. Elle 
comprend des sequences de taches, appelees nids de boucles, bien 
structurees et paralleles. Chaque nid de boucles contient un appel a une 
procedure ou macro-instruction correspondant en general a une 

20 transformation de tableau c'est a dire a une fonction d'une librairie de 
traitement du signal telle qu'une FFT. Les traitements sont reguliers et 
s'effectuent sur des signaux multidimensionnels, les donnees sont 
organisees en tableaux dont les dimensions (par exemple source, frequence, 
temps recurrence, temps pointage) portent les vecteurs sur lesquels vont 

25 s'effectuer les traitements individuels. L'application est globalement 
representee par un graphe de flot de donnees acyclique dans lequel chaque 
element de tableau n'est mis qu'une seule fois a jour par l'application. Enfin, 
le deroulement de l'application ne decoule pas d'evenements exterieurs ni de 
resultats de calcul apparaissant lors de I'execution, ce qui fait que ce 

30 deroulement est previsible. En d'autres termes, le deroulement de 
l'application est deterministe. 

Bien entendu, I'invention s'applique a tout type d'application de 
TSS, notamment aux applications deterministes par parties. Ces applications 
deterministes par parties comprennent des sequences de traitements 

35 deterministes de duree limitee, qui se succedent dans le temps dans un 
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ordre non previsible a priori. C'est le cas des traitements radar multi-mode 
par exemple. 

Lors d'une etape E1 de placement, les taches de calcul sont 
reparties sur plusieurs groupes d'unites de calcul d'une architecture cible 
5 particuliere. On se refere a la figure 2 sur laquelle est represents un exemple 
de placement sous la forme d'un schema synoptique. Ce placement peut 
comprendre une dtape de partitionnement P1 et une etape d'affectation P2. 

Le partitionnement P1 peut se faire suivant les taches ou suivant 
les donnees. Le partitionnement suivant les taches (parallelisme de taches) 

10 permet par exemple de diviser un calcul en plusieurs etapes elementaires 
disjointes de calcul, representees par des taches ou des ensembles de 
taches. Ces etapes elementaires disjointes sont destinees a etre executees 
par des sous-ensembles disjoints de ('architecture cible appeles segments. 
Le partitionnement suivant les donnees (parallelisme de donnees) permet 

15 par exemple de diviser les donnees utilisees par ces etapes elementaires 
disjointes en plusieurs groupes de donnees, representes par des parties de 
tableaux. Ces groupes de donnees sont destines a etre traites par des sous 
ensembles disjoints de I'architecture cible. 

Lors de I'etape d'affectation P2, les etapes elementaires disjointes 

20 de calcul peuvent etre allouees par exemple a des segments d'architecture. 
Notamment, les taches de calcul peuvent etre allouees a des groupes 
d'unites de calcul. De plus, les groupes de donnees utilisees par ces etapes 
elementaires disjointes peuvent etre alloues a des parties des segments 
d'architecture. Notamment, les differentes parties d'un tableau de donnees 

25 peuvent etre allouees a differentes unites de calcul d'un segment. 
L'affectation P2 permet de determiner quelles ressources A1 de I'architecture 
cible sont impliquees lors de I'execution d'une tache. 

Les taches de calcul permettent de realiser des operations sur des 
donnees, telles que des filtrages numeriques. L'application est destinee a 

30 etre executee sur une architecture particuliere. Cette architecture comprend 
des services permettant d'effectuer ces calculs. L'architecture comprend 
aussi des services permettant d'effectuer des mouvements de donnees. Un 
mouvement de donnees se decompose en plusieurs services. Par exemple 
un premier service permet de programmer un controleur DMA (abreviation de 

35 I'expression anglo-saxonne « Direct Memory Acces »), un second service 
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permet d'effectuer la suite du mouvement de donnees. Ces services bien sur 
varient d'une architecture a une autre. Ainsi une meme application realisant 
une meme fonction s'ecrit difteremment selon I'architecture sur laquelle elle 
est destinee a. etre executee. 

5 Selon I'invention, de maniere a reduire le temps necessaire a la 

realisation des applications multiprocesseurs, on cree une interface de 
programmation plus haut niveau que les services. A cet effet, les services 
sont regroupes dans des mecanismes A2. Les mecanismes A2 dependent 
de I'architecture cible. Us correspondent aux fonctionnalites utilisees par les 

10 taches. Un mecanisme est une operation repetee plusieurs fois par une 
ta.che. II existe des mecanismes de calcul et des mecanismes de mouvement 
de donnees. Les mecanismes de calcul represented les fonctions 
susceptibles d'apparaitre dans la description fonctionnelle D1 de 
I'application. Ces mecanismes peuvent correspondre a des fonctions de 

15 base d'une bibliotheque telles que le produit scalaire ou la transformation de 
Fourier discrete. Ces mecanismes peuvent aussi correspondre a. des 
fonctions specifiques d'une application particuliere, tel qu'une fonction de 
compression ou de cryptage. Les mecanismes de mouvement de donnees 
permettent par exemple de deplacer les donnees d'un tableau, reparties 

20 dans un premier ensemble de memoires de I'architecture cible, vers un 
second ensemble de memoires de I'architecture cible. 

Les etapes de partitionnement P1 et d'affectation P2 peuvent etre 
realisee de fagon manuelle par le mappeur avec I'aide d'un outil de 
placement. Lors du patitionnement P1 , une liste des mecanismes A2 de 

25 I'architecture peut etre utilisee par I'outil de placement. Lors de I'affectation 
P2, une liste des ressources A1 de I'architecture peut etre utilisee par I'outil 
de placement. A la fin du placement E1 , on dispose d'un graphe de taches 
D2, lesdites taches etant affectees aux ressources de I'architecture cible. 

On se refere a nouveau a la figure 1 pour la suite de la description 

30 de I'exemple de realisation d'application multiprocesseurs. Lors d'une 
seconde etape E2, le graphe de taches est converti en un graphe de 
services D3. Cette etape E2 permet de preparer une simulation de 
I' execution de I'application sur I'architecture cible. 

Avantageusement, cette etape D2 de preparation de la simulation 

35 est realisee de maniere automatique par I'atelier. A cet effet, pour chaque 
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tache du graphe de taches, le mecanisme associe a la tache est converti en 
un ensemble de services. Pour effectuer cette conversion, I'atel'ier utilise la 
definition de chaque mecanisme, c'est a dire la liste des services 
correspondant a chaque mecanisme. 

5 Le graphe de service D3 peut alors etre utilise lors d'une etape de 

simulation E3. Cette simulation permet de determiner les performances de 
I'application placee. Si ces performances ne sont pas satisfaisantes, le 
mappeur peut modifier ce placement avec I'aide de I'outil de placement, et 
relancer une simulation. 

10 Lors de la simulation, I'atelier utilise un modele comportemental 

A3 de I'architecture cible. Ce modele A3 permet de decrire le comportement 
de I'architecture face aux sollicitations des services, c'est a dire lors de 
('execution de I'application. Ce modele A3 permet notamment de determiner 
I'utilisation des ressources de I'architecture cible au cours de I'execution des 

15 services. Par exemple un service de mouvement qui utilise un bus de 
donnees peut etre ralenti si ce bus est deja utilise par un autre service. Le 
modele A3 permet aussi de determiner I'ordre d'execution des services parmi 
la liste des services pouvant s'executer a un instant donne. 

Les informations AC relatives a une architecture cible particuliere, 

20 qui sont utilisees par I'atelier, comprennent : 

• la liste des ressources A1 , 

• la liste de mecanismes et leurs definitions A2, 

• et un modele comportemental A3. 

Ces informations AC sont memorisees sous une forme qui permet 
25 d'adapter facilement I'atelier a de nouvelles architectures cibles. 

On se refere maintenant a la figure 3 sur laquelle est represents un exemple 
d'atelier de placement AT permettant de mettre en ceuvre le procede de 
realisation d'application illustre figure 1 . Cet atelier comprend un outil d'aide 
au placement G1, un modele d'architecture A3, et un moteur de simulation 
30 G2. L'outil d'aide au placement G1 permet de realiser le placement de 
I'application, tel que celui illustre figure 2. Le modele d'architecture A3 est 
utilise lors de la simulation par le moteur de simulation G2 pour determiner 
les performances D4 de I'application placee. La liste des ressources A1 et la 
liste de mecanismes et leurs definitions A2 peut etre memorisee dans un ou 
35 plusieurs fichiers de texte, interprets par I'atelier de placement. A cet effet, 
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des moyens de lecture de la liste des ressources A1 de I'architecture cible 
d'une part, et de la liste de mecanismes et leurs definitions A2 d'autre part 
peuvent etre integres a I'atelier AT. 

Une architecture cible peut comprendre des ressources telles que 

5 des unites de calcul, des memoires, des bus de donnees. La liste des 
ressources A1 comprend une description de I'organisation des ces 
ressources. Ces ressources sont generalement organisees maniere reguliere 
de maniere a' permettre de paralleliser les calculs effectues par I'application. 
La liste de ressources A1est utilisee lors de I'etape de placement E1 d'une 

10 part, et lors de I'etape de simulation E3 d'autre part. Lors de I'etape de 
placement E1 , la liste des unites de calcul et des memoires est utilisee. Lors 
de l'6tape de simulation E3, la liste complete des ressources est utilisee. 

On appelle architecture segment chacun des sous-ensembles de 
I'architecture cible sur lequel s'effectuent des calculs mettant en oeuvre du 

15 parallelisme de donnees. On appelle architecture segment repetitive, une 
architecture segment dont les ressources sont agencees d'une maniere 
reguliere, de maniere a pouvoir etre regroupees dans des tableaux 
d'elements identiques. Lorsque ces tableaux ont plusieurs dimensions, ces 
dimensions peuvent se representor par des niveaux. Un niveau correspond 

20 souvent a line ressource de I'architecture, telle qu'une carte electronique, sur 
laquelle sont disposees d'autres ressources, telles que des memoires par 
exemple. Chaque niveau comprend des elements, tels que des ensembles 
homogenes d'une part, et / ou des ressources specifiques d'autre part. Les 
ensembles homogenes d'un niveau peuvent comprendre a leur tour des 

25 Elements de niveau inferieur. 

La liste des ressources A1 d'une architecture segment repetitive 
peut etre decrite dans un fichier formate en lignes et colonnes d'un tableau 
tel que : 



BLOC 


Tiger 






UC 


UcTiger 


1 


150 MHz 


MEM 


Ramlnt 


4000 Ko 


400 Ko/s 


MEM 


RamProg 


2000 Ko 


600 Mo/s 


BUS 


PortLien 


150 Mo/s 




BUS 


PortBus 


1200 Mo/s 
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AUTRE 


Dma 


8 




FIN 








BLOC 


Carte 






INC 


Tiger 


6 




MEM 


Ram Ext 


1024KO 


600 Mo/s 


MEM 


DPRam 


500 Ko 


1000 Mo/s 


BUS 


BusExt 


600 Mo/s 




BUS 


Liensln 


300 Mo/s 




BUS 


Lienslnter 


150 Mo/s 




FIN 








SEGMENT 


SegA 






INC 


Carte 


8 




BUS 


Reseau 


133 Mo/s 




FIN 








SEGMENT 


SegB 






INC 


Carte 


4 




BUS 


Reseau 


133 Mo/s 




FIN 









La premfere colonne de ce tableau comprend des mots clefs. Ces 
mots clef sont « BLOC », « UC », « MEM », « BUS », « AUTRE », « FIN », 
« INC », et « SEGMENT ». 

5 Les mots clefs « UC », « MEM », « BUS », et « AUTRE » 

representent des ressources de type unite de calcul, memoire, bus ou autre, 
lis sont suivis par le nom de la ressource, et des parametres caracteristiques 
de cette ressource. Ainsi, a la cinquieme ligne de ce tableau, il apparatt que 
I'architecture cible comprend des bus nommes « PortLien » caracterises par 

10 un taux de transfer! de 1 50 Mo/s. 

Les mots clefs « BLOC » et « SEGMENT » representent des 
groupes de ressources, dont le nom suit le mot clef. Chaque groupe se 
termine par le mot clef « FIN ». Toutes les ressources d'un groupe de 
ressources sont du meme niveau dans I'architecture. 

15 Un groupe de ressources peut etre considere comme une 

ressource d'un autre groupe de niveau superieur. Lorsqu'un groupe de 
ressources est inclus dans un groupe de ressources de niveau superieur, on 
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utilise le mot clef « INC » suivi du nom du groupe et du nombre 
d'occurrences de ce groupe. Ainsi, a la dixieme ligne de ce tableau il 
apparaft que le groupe « Carte » comprend six occurrences du groupe 
« Tiger ». 

Bien entendu, il est possible de decrire la liste des ressources A1 
differemment a I'aide d'un fichier binaire par exemple. 



La liste des mecanismes et leurs definitions A2 peut etre decrite 
dans un fichier formate en lignes et colonnes d'un tableau tel que : 



CALC 


Tiger 


Mulac 




IN 


Ramlnt 


Complex32 


8 


IN 


Ramlnt 


Complex32 


8 


OUT 


Ramlnt 


Complex32 


1 


CYCLES 


5 


1 


3 


FIN 








CALC 


Tiger 


FFT512 




IN 


Ramlnt 


Complex32 


512 


IN 


Ramlnt 


Complex32 


512 


OUT 


Ramlnt 


Complex32 


512 


CYCLES 


10 


4608 


12 


FIN 








MOUV 


Carte 


DPtol 




SOURCE 


DPRam 






DEST 


Ramlnt 






LOI 


XA->XY 






SERVICE 


CoreService 


S DPtol 




FIN 








MOUV 


Carte 


Itol 




SOURCE 


Ramlnt 






DEST 


Ramlnt 






LOI 


XYA->XAY 






SERVICE 


CoreService 


S Itol 




FIN 








MOUV 


Carte 


ItoE 
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SOURCE 


Ramlnt 






DEST 


Ram Ext 






LOI 


XY->XA 






SERVICE 


CoreService 


SJtoE 




FIN 








MOUV 


Carte 


Etol 




SOURCE 


Ram Ext 






DEST 


Ramlnt 






LOI 


XA->XY 






SERVICE 


CoreService 


S_Etol 




FIN 








MOUV 


Carte 


EtoE 




SOURCE 


Ram Ext 






DEST 


Ram Ext 






LOI 


XA->AX 






SERVICE 


CoreService 


S_EtoE 




FIN 








MOUV 


SeqA 


AtoB 




SOURCE 


RamExt 






DEST 


RamExt->SegB 






LOI 


XA->AX 






SERVICE 


CoreService 


ProgDMAext 




SERVICE 


NetworkService 


S AtoB 




FIN 









La premiere colonne de ce tableau comprend des mots clefs. Ces 
mots clef sont « CALC » t « MOUV », « FIN », « IN », « OUT », « CYCLES », 
« SOURCE », « DEST », « LOI », « SERVICE ». 

5 Les mots clefs « CALC » et « MOUV » represented 

respectivement des mecanismes de calcul et de mouvement de donnees. lis 
sont suivis par le nom du groupe de ressources permettant de mettre en 
oeuvre le mecanisme, et par le nom du mecanisme. Ainsi, a la premiere ligne 
du tableau, il apparait que le mecanisme de calcul « Mulac » est destine a 

10 etre mis en oeuvre par le groupe de ressources « Tiger ». La definition d'un 
mecanisme de calcul ou de mouvement s'arrete avec le mot clef « FIN ». 
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Les mots clefs « IN », « OUT » representent respectivement les 
entrees et les sorties des m6canismes de calcul. lis sont suivis par le nom de 
la memoire dans laquelle sont memorisees les donnees, la nature des 
donnees (entier, r6el, complexe) utilisees, et le nombre de donnees. Ainsi, le 
mecanisme de cacul « Mulac » utilise en entree deux tableaux de 8 nombres 
de type « Complex32 » memorises dans une memoire « Ramlnt » et produit 
en sortie un nombre de type « Comple32 » memorise dans une mdmoire 
« Ramlnt ». 

Le mot clef « CYCLES » repr^sente le nombre de cycles utilises 
par un mecanisme de calcul. II est suivi par le nombre de cycle de t§te, de 
corps et de queue. En d'autres termes, le mot clef « CYCLES » est suivi par 
trois nombres entiers qui representent le nombre de cycles necessaire a 
('initialisation du calcul, lors d'une iteration, et a la fin du calcul. 

Les mots clef « SOURCE » et « DEST » representent 
respectivement les memoires de depart et d'arriv6e d'un mecanisme de 
mouvement. lis sont suivis par le nom des memoires de depart et d'arrivee. 
Ainsi le mecanisme de mouvement « Etol » permet de deplacer des donnees 
d'une memoire « RamExt » vers une memoire « Ramlnt ». Le mot clef 
« LOI » represente la maniere dont les donnees changent de repartition 
d'une memoire a une autre. II est suivi par un nom correspondant a ce 
changement de repartition. 

Le mot clef « SERVICE » represente I'un des services permettant 
de mettre en oeuvre un mecanisme de mouvement. Ce mot clef est suivi du 
type de service et du nom du service. Ainsi le mouvement de donnees 
. « AtoB » se decompose en deux services : « ProgDMAext » de type 
« CoreService » d'une part, et « S_AtoB » de type « NetworkService » 
d'autre part. 

Bien entendu, il est possible de d^crire la liste des mecanismes et 
leurs definitions A2 differemment a I'aide d'un fichier binaire par exemple. 

L'atelier de placement AT peut etre realise en utilisant un langage 
de programmation objet tel que le C++. En d'autres termes, tous les modules 
de l'atelier AT peuvent etre realises en utilisant le langage objet C++. Le 
modele comportemental A3 fait alors partie integrante de l'atelier. II. peut etre 
compile avec ce dernier ou etre compile separement dans une librairie 
dynamique par exemple. Bien entendu, les differents modules de l'atelier 
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peuvent etre realises en utilisant des langages de programmation differents, 
en utilisant des techniques d'encapsulation par exemple. 

On se refere maintenant a la figure 4 sur laquelle est illustre un 
exemple de modele comportemental A3 sous la forme d'un diagramme 

5 d'objets. Ce modele comportemental A3 est utilise lors de la simulation. II 
permet notamment de determiner si un service peut s'executer a un instant 
donne de la simulation, et si oui a quelle vitesse en fonction de I'utilisation 
des ressources de I'architecture cible a cet instant donne de la simulation. Le 
modele comportemental A3 illustre figure 4 est un objet composite 

10 comprenant plusieurs objets A30, A31 , A32, A33, A34, A35. Les objets A30, 
A31, A32, A33, A34, A35 comprennent des modeles comportementaux. Ces 
objets sont des instances de classes heritant des proprietes d'une classe 
commune. Cette classe commune permet de definir des methodes 
generiques des modeles comportementaux. Ces methodes generiques sont 

15 utilisees par le moteur de simulation. Lorsque I'architecture cible est 
modifiee, les modeles comportementaux doivent etre adaptes a la nouvelle 
architecture cible. Grace a cette structure de modele utilisant des methodes 
generiques, il n'est pas necessaire de modifier les autres parties de I'atelier 
AT, notamment le moteur de simulation G2. 

20 Avantageusement, objets A30, A31, A32, A33, A34, A35 sont 

organises en niveaux de la meme maniere que les ressources de 
I'architecture cible. Ainsi les objets correspondant a un niveau comprennent 
des references a des objets correspondant a des niveaux inferieurs. Par 
exemple I'objet comprenant le modele comportemental d'architecture A30 

25 comprend une reference a un objet comprenant un modele comportemental 
de carte A32 d'une part, et une reference a un objet comprenant un modele 
comportemental de reseau A31 d'autre part. De meme, I'objet comprenant 
un modele comportemental de reseau A31 comprend une reference a I'objet 
comprenant un modele comportemental de bus A33. L'objet comprenant un 

30 modele comportemental de carte A32 comprend une reference a I'objet 
comprenant un modele comportemental de memoire A34 d'une part, et une 
reference a I'objet comprenant un modele comportemental d'unite de calcul 
A35 d'autre part. 
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On se refere maintenant a la figure 5 sur laquelle est illustre un 
exemple d'objets utilises dans I'atelier de placement AT lors d'une simulation, 
sous la forme d'un diagramme d'objets. 

La plupart des donnees necessaires au moteur de simulation G2 
peuvent etre memorisees dans un objet MS. Cet objet relatif au moteur de 
simulation MS permet notamment de memoriser I'heure simulee, I'etat 
d'occupation des ressources (memoires et unites de calcul), et la liste des 
taches en cours d'execution. A cet effet, cet objet MS du moteur de 
simulation peut comprendre des references a d'autres objets RS, SC 
representant respectivement les ressources de ('architecture cible d'une part, 
et ses services d'autre part. 

Les objets RS representant les ressources de I'architecture cible 
comprennent des attributs dans lesquels sont memorises les parametres 
caracteristiques des ressources. Ces parametres, tel que le taux de transfert 
d'un bus, peuvent etre lus par I'atelier de placement AT dans un fichier 
comprenant la liste des ressources A1 . Ce fichier comprenant la liste des 
ressources A1 peut etre celui cite precedemment. A la lecture de ce fichier, 
des objets ressource RS peuvent etre crees pour chaque ressource de 
I'architecture cible. Selon un premier mode de realisation avantageux, un 
objet ressource RS peut correspondre a un groupe de ressources identiques 
de I'architecture cible. Un seul objet ressource RS peut etre cree pour 
representer un tableau de ressources. Cet objet RS comprend un attribut 
pour memoriser le nombre de ressources presentes dans I'architecture cible. 
Pour une architecture segment repetitive par exemple, cet attribut peut etre 
un tableau d'entiers. Le produit des entiers de ce tableau correspond au 
nombre de ces ressources presentes dans I'architecture cible. Les 
dimensions de ce tableau correspondent aux niveaux de I'architecture cible. 

Selon une variante avantageuse, un objet ressource RS peut 
correspondre a un groupe de ressources. II comprend alors une reference a 
d'autres objets ressources RS representant des groupes de ressources ou 
des ressources a leur tour. Ces groupes de ressources sont representes par 
les mots clefs « BLOC » et « SEGMENT » dans I'exemple de fichier cite 
precedemment. 

On se refere maintenant a la figure 6 sur laquelle est illustre un 
exemple de diagramme de classes correspondant aux ressources de 
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I'architecture cible. Un objet ressource RS est une instance d'une classe 
d'objet ressource. On utilise la meme reference RS pour designer I'objet et la 
classe. Selon un mode de realisation avantageux, des classes d'objets 
sp^cialisees R1, R2, R3 peuvent correspondre respectivement a des bus, 
5 des unites de calcul, et des memoires. Ces classes d'objets R1, R2, R3 
heritent des proprietes de la classe d'objet ressource RS. Si le mot clef 
« BUS » apparait de fichier comprenant la liste des ressources A1 , I'outil de 
placement AT peut creer un objet en instanciant la classe R1 . De meme pour 
le mot clef « UC », I'outil de placement AT peut creer un objet en instanciant 
10 la classe R2. Pour le mot clef « BUS », I'outil de placement AT peut creer un 
objet en instanciant la classe R3. Pour le mot clef « AUTRE », I'outil de 
placement AT peut creer un objet en instanciant la classe RS. 

Avantageusement, il est possible de definir d'autres classes 
d'objet ressource plus specialisees R4, R5, R6 correspondant a des bus 
15 particuliers, des unites de calcul particulieres, et des memoires particulieres 
par exemple. Ces classes R4, R5, R6 heritent alors de proprietes des 
classes R1 , R2, R3 respectivement. D'autres mots clef pourront alors etre 
utilises dans le fichier de description A1 de I'architecture pour designer ces 
ressources particulieres. De cette maniere, il est possible de changer 
20 d'architecture cible facilement, meme lorsqu'il est necessaire de definir des 
ressources specialisees. Seuls les parties essentielles de I'atelier de 
placement AT sont modifiees. De nouveaux modeles comportementaux 
peuvent etre ajoutes ou modifies, de nouvelles classes de ressources R4, 
R5, R6 ajoutees ou modifiees, sans modifier le reste de I'atelier AT. 
25 Les objets MC representant les mecanismes de I'architecture cible 

comprennent des attributs dans lesquels sont memorises les parametres 
caracteristiques des mecanismes. Certains parametres, tel que le nombre et 
de type d'elements utilises en entree par un mecanisme de calcul, peuvent 
etre lus par I'atelier de placement AT dans un fichier comprenant la liste des 
30 mecanismes et leurs definitions A2. Ce fichier comprenant la liste des 
mecanismes et leurs definitions A2 peut etre celui cite precedemment. Les 
objets mecanisme MC peuvent etre crees apres la lecture des parametres 
presents dans ce fichier. 

On se refere maintenant a la figure 7 sur laquelle est illustre un 
35 exemple de diagramme de classes correspondant a des mecanismes. Un 
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objet mecanisme MC est une instance d'une classe d'objet mecanisme. On 
utilise la meme reference MC pour designer I'objet et la classe. Selon un 
mode de realisation avantageux, des classes d'objets specialisees M1, M2 
peuvent correspondre respectivement a des mecanismes de calcul et a des 
mecanismes de mouvement. Ces classes d'objets M1, M2 heritent des 
proprietes de la classe d'objet mecanisme MC. Si le mot clef « CALCUL » 
apparatt de fichier comprenant la liste des mecanismes et leurs definitions 
A2, Poutil de placement AT peut creer un objet en instanciant la classe M1. 
De meme pour le mot clef « MOUVEMENT », I'outil de placement AT peut 
creer un objet en instanciant la classe M2. 

Avantageusement, il est possible de definir d'autres classes 
d'objet mecanisme plus specialisees M3, M4 correspondant a des calculs 
particuliers, et des mouvements particuliers par exemple. Ces classes M3, 
M4 heritent alors de proprietes des classes M1, M2 respectivement. D'autres 
mots clef pourront alors etre utilises dans le fichier de description A2 de 
I'architecture pour designer ces mecanismes particuliers. De cette maniere.il 
est possible de changer d'architecture cible facilement, meme lorsqu'il est 
necessaire de definir des services specialises. Seuls les parties essentielles 
de I'atelier de placement AT sont modifiees. De nouvelles classes de 
mecanismes M3, M4 peuvent etre ajoutees ou modifiees, sans modifier le 
reste de I'atelier AT. 

On se revere maintenant a la figure 8 sur laquelle est illustre un 
exemple d'objets utilises lors de I'etape E2 de preparation de la simulation, 
sous la forme d'un diagramme d'objets. 

A partir de la description de Papplication non placee D1 , I'atelier de 
placement AT peut generer un graphe de taches non placees. Ces taches 
peuvent etre representees par des objets TA comprenant des attributs 
relatifs a ces taches. L'un des attributs des objets TA peut etre une reference 
a I'objet mecanisme MC correspondant au mecanisme utilise par la tache. 
De meme, l'un des attributs de I'objet mecanisme MC peut etre une 
reference a I'objet tache TA. Lors de I'etape de preparation de la simulation, 
I'objet mecanisme MC peut generer des objets services SC. L'objet 
mecanisme MC peut comprendre parmi ses attributs des references aux 
objets services SC cr66s. De meme les objets services SC peuvent 
comprendre parmi leurs attributs une reference a I'objet mecanisme MC les 
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ayant crees. De plus les objets services SC peuvent comprendre parmi leurs 
attributs une reference a I'objet tache TA. De cette maniere, a partir du 
graphe de tache D2 represents par des objets taches TA, on obtient un 
graphe de services D3 represents par des objets services D3. 

5 On se refere maintenant aux figures 9, 10, et 11 sur lesquelles 

sont illustres des exemples de classes TA, MC, SC, correspondant a des 
taches, des mScanismes et des services. 

La classe d'objet tache TA illustree figure 9 comprend des attributs 
T01 , T02, T03, T04, T05, T06, T07. L'attribut T01 est une reference a un 

10 objet mecanisme. L'attribut T02 est un entier ou un tableau d'entiers utilise 
lors de d'etape de placement E1 . Ces entiers correspondent a un nombre de 
ressources de I'architecture cible utilisees en parallele. Par exemple, si une 
tache de calcul est effectuee en parallele sur 10 cartes comprenant chacune 
5 unites de calcul, ces nombres seront 10 et 5. L'attribut T03 correspond a 

15 un nombre d'iteYations effectuees de facon sequentielle (pas en parallele) par 
la tache. Une tache peut comprendre plusieurs boucles imbriquees, par 
exemple une premiere boucle de 8 iterations, dans laquelle est imbriquee 
une autre boucle de 32 iterations. Dans ce cas l'attribut T03 comprendra les 
nombres 8 et 32. Le nombre d'iterations totales effectuees par la tache est le 

20 produit de ces nombres, c'est a dire 8 fois 32. Le nombre total de calculs 
elementaires effectues de maniere sequentielle ou en parallele est le produit 
des premiers nombres memorises dans l'attribut T02 et des seconds 
nombres memorises dans l'attribut T03. 

Les attributs T04 et T05 sont des references a des objets 

25 representant les tableaux utilises par la tache respectivement en entree et en 
sortie. Par exemple une tache de calcul utilise deux tableaux d'entrees et un 
tableau de sortie. Le premier tableau d'entee contient des donnees 
mesurees, et le second les coefficients d'un filtre numerique. Le tableau de 
sortie est la somme de plusieurs donnees du premier tableau, ponderee par 

30 les coefficients du second tableau. L'attribut T04 comprend alors une 
reference aux objets representant les deux tableaux d'entree. L'attribut T05 
comprend alors une reference aux objets representant le tableau de sortie. 

L'attribut T06 est une reference a des objets tache. Les taches 
correspondant aux objets references par l'attribut T06 sont celles permettant 

35 de produire les tableaux d'entree. Les taches referencees par l'attribut T06 
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sont appelees des taches productrices, la tache les referencant est appelee 
une tache consommatrice. Les tableaux de sortie des taches productrices 
sont utilises comme tableau d'entree par la tache consommatrice. Une tache 
peut etre une tache productrice vis a vis d'une premiere tache, et 
consommatrice vis a vis d'une autre tache. L'attribut T06 permet de 
construire un graphe de taches, mettant en evidence les relations de 
production et de consommation de donnees (taches productrices / taches 
consommatrices). II permet en outre de determiner des premieres relations 
de precedences entre les taches. En effet, une tache consommatrice ne peut 
pas s'executer avant I'appel d'une tache productrice. 

L'objet tache TA peut comprendre en outre d'autres informations 
de precedences memorisees dans l'attribut T07. Ces informations peuvent 
etre des references a d'autres objets taches. Elles peuvent etre donnees par 
le mappeur par exemple lors de I'etape E1 de placement. 

La classe d'objet mecanisme MC illustree figure 1 0 comprend des 
attributs M01, M02. L'attribut M01 est une reference a un objet tache. 
L'attribut M02 comprend des references a des objets services. 

Les classes d'objets specialisees M1, M2, correspondant 
respectivement a des mecanismes de calcul et a des mecanismes de 
mouvement, comprennent des attributs qui leurs sont propres. La classe 
d'objet mecanisme de calcul M1 comprend des attributs M10, M11, M12, 
M13, M14, M15. La classe d'objet mecanisme de mouvement M2 comprend 
des attributs M20. M21 , M22. 

Les attributs M10, M11 permettent de determiner quelles 
memoires de I'architecture cibles sont utilisees respectivement pour 
memoriser les. tableaux d'entree et les tableaux de sortie de la tache de 
calcul. Ces attributs peuvent etre renseignes par le mappeur lors de I'etape 
d'affectation P2. 

Les attributs M12, M13, M14 permettent de determiner les 
performances de I'application placee lors d'une simulation. L'attribut M12 
peut correspondre au nombre de lignes de codes necessaires a I'execution 
du mecanisme sur I'architecture cible. Utilisation de cet attribut lors de 
I'etape de simulation E3 permet de determiner quelle place memoire est 
necessaire pour executer le mecanisme. L'attribut M13 peut correspondre au 
nombre de cycles necessaires a ('initialisation du calcul, lors d'une iteration, 
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et a la fin du calcul. Uattribut M14 peut cdrrespondre au nombre d'entrees / 
sorties necessaires lors d'une iteration. Les attributs M12, M13 et M14 
peuvent etre renseignes a partir de la lecture d'un fichier contenant la liste 
des mecanismes et leurs definitions A2. Par exemple Pattribut M13 peut 
5 comprendre les donnees suivant le mot clef « CYCLES » et Pattribut M14 les 
donnees suivant les mots clef « IN » et « OUT ». 

Uattribut M15 permet de determiner quelles unites de calcul sont 
utilisees pour executer le mecanisme. Cet attribut peut etre renseigne par le 
mappeur lors de Petape d'affectation P2. 

10 Les attributs M20 et M21 permettent de determiner les memoires 

depart et d'arrivee du mecanisme de mouvement. Ces attributs peuvent etre 
renseignes a partir de la lecture d'un fichier contenant la liste des 
mecanismes et leurs definitions A2. Par exemple Pattribut M20 peut 
comprendre les donnees suivant le mot clef « SOURCE », et Pattribut M21 

15 les donnees suivant le mot clef « DEST ». 

Uattribut M22 permet de determiner le nombre de donnees 
transferees par iteration. Chaque iteration permet de deplacer plusieurs 
donnees des memoires de depart vers les memoires d'arrivee. Cet attribut 
permet de determiner leur nombre. II peut etre utilise lors de Petape de 

20 simulation pour determiner la Vitesse d'execution du mouvement de 
donnees. 

La classe d'objet service SC illustree figure 11 comprend des 
attributs S01 , S02, S03, S04, S05, S06, S07, S08. 

Uattribut S01 est une reference a un objet tache. Uattribut S02 est 

25 une reference a un objet mecanisme. Uattribut S03 permet de determiner la 
categorie du service. Selon sa categorie, un service peut par exemple 
r^server des ressources, liberer des ressources, ou ni rdserver ni liberer de 
ressource. Cet attribut peut etre renseigne lors de la creation de Pobjet 
service par un objet mecanisme. L'objet mecanisme comprend par exemple 

30 une methode permettant de creer des objets services. Lors de Pexecution de 
cette methode, certains attributs des objets services, tel que Pattribut S03, 
sont initialises. 

Uattribut S04 permet de determiner Petat d'un service au cours 
d'une simulation E3. Un service peut par exemple etre en attente (etat 
35 service en attente), en cours d'execution (etat service en cours), ou son 
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execution terminee (etat service fini). Cet attribut S04 est mis a jour en cours 
de simulation. 

Les attributs S05 et S06 permettent de determiner I'avancement 
d'execution du service. L'attribut S05 correspond au nombre d'iterations 
totales a executer. En d'autres termes l'attribut S05 correspond au nombre 
d'iterations initiales du service. L'attribut S06, mis a jour en cours de 
simulation, correspond au nombre d'iterations restantes du service. Avant le 
iancement du service, le nombre d'iterations initiales est egal au nombre 
d'iterations restantes. A la fin de son execution, le nombre d'iterations 
restantes est nul. 

L'attribut S07 correspond a la vitesse d'execution du service. 
Cette vitesse peut etre exprimee en nombre de cycles par iterations. Elle 
depend notamment de I'utilisation des ressources de I'architecture cible. Elle 
est mise a jour en cours de simulation en utilisant le modele A3 
d'architecture. 

L'attribut S08 comprend des references a des objets services. Ces 
objets services correspondent a la liste des services a attendre avant 
d'executer le service. Cet attribut S08 peut etre renseigne lors de la creation 
de I'objet service, en utilisant notamment les attributs T06 et T07 de I'objet 
tache dont resulte I'objet service. 

On se revere maintenant a la figure 12 sur laquelle est illustre un 
exemple de simulation E3. 

Au debut C01 de la simulation E3, le moteur de simulation G2 fait 
le choix C02 d'un service a lancer parmi les services dont la liste d'attente 
est vide (attribut S08 des objets services). Puis un test C03 est effectu6 pour 
determiner si le service dispose des ressources necessaires pour son 
execution. Si c'est le cas, le moteur de simulation lance le service lors d'une 
etape C04 en mettant a jour l'attribut S04 de I'objet service. 

En utilisant le modele d'architecture A3, la vitesse d'execution du 
service lance est alors renseignee lors d'une 6tape C05 en mettant a jour 
l'attribut S07 de I'objet service correspondant. Apres le Iancement C05 du 
service, I'utilisation des ressources de I'architecture est differente. De la 
meme maniere, la vitesse d'execution des autres services lances est alors 
mise a jour lors d'une etape C06. 
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Puis lors d'une etape C07, on utilise les attributs S06 et S07 des 
objets services lances pour determiner les heures de fin d'execution des 
services en cours. Les attributs S06 et S07 correspondent au nombre 
d'iterations restantes et a la vitesse d'execution des services lances. 
5 Puis lors d'une etape C08, en comparant les heures determinees 

a I'etape C07, on determine I'echeance la plus proche, c'est a dire celle 
arrivant en premier dans la simulation. En d'autres termes, on determine lors 
des etapes C07 et C08 quel service aura fini de s'executer le premier. 

Puis lors d'une etape C09, I'heure simulee est incrementee de 
10 maniere a §tre 6gale a I'echeance la plus proche determinee a I'etape C08. 
Cette heure simulee peut etre memorisee dans un attribut du moteur de 
simulation par exemple. Les attributs S06 et S04 des services en cours 
d'execution sont alors mis a jour lors d'une etape C10. 

Puis lors d'un test C1 1 , on determine si le dernier service en cours 
15 d'execution est maintenant fini (attribut S04). Si tel est le cas la simulation, 
c'est la fin C13 de la simulation. Sinon, la simulation continue a I'etape C02. 

Lors du test C03, si le service selectionne ne peut pas etre lance, 
celui-ci est mis en attente lors d'une etape C12, et la simulation continue a 
I'etape C07. 

20 Tout au long de cette simulation, des parametres tel que I'etat 

d'occupation des ressources, ou les taches en cours d'execution (c'est a dire 
celles dont les services sont en cours d'execution), sont enregistres par le 
moteur de simulation avec I'heure simulee. Ces parametres sont des 
indicateurs des performances D4 de ('application placee. 

25 Bien entendu, I'invention ne se limite pas aux exemples decrit ci- 

avant. L'atelier peut etre programme en utilisant un autre langage, la 
structure des objets decrits peut etre differentes, certains objets peuvent etre 
remplaces par des groupes d'objets, et plusieurs objets peuvent etre 
regroupes en un seul objet. 

30 
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REVINDICATIONS 

1. Procede de simulation d'une application multiprocesseur placee sur une 
architecture cible, caracterise en ce qu'il comprend au moins les etapes 
suivantes : 

(a) une etape (E2) de preparation de la simulation, pour produire un graphe 
5 (D3) de services, a partir d'un graphe (D2) de taches d'une part, et d'une 

liste de mecanismes et leurs definition (A2) d'autre part ; 

(b) une etape (E3) d'execution de la simulation, pour determiner les 
performances de I'application placee, a partir d'urt modele 
comportemental (A3) de I'architecture cible d'une part, et du graphe (D3) 

10 de services d'autre part. 

2. Procede realisation d'une application multiprocesseur, caracterise en ce 
qu'il comprend au moins les etapes suivantes : 

(a) une etape (E1) de placement de I'application sur I'architecture cible, en 
15 utilisant une description (D1) fonctionnelle de ladite application d'une 

part, et la liste des ressources (A1) de I'architecture cible d'autre part, de 
maniere a produire un graphe (D2) de taches ; 

(b) une etape (E2) de preparation d'une simulation pour produire un graphe 
(D3) de services, a partir d'un graphe (D2) de taches d'une part, etd'une 

20 liste de mecanismes et leurs definition (A2) d'autre part ; 

(c) une etape (E3) d'execution de la simulation, pour determiner les 
performances de I'application placee, a partir d'un modele 
comportemental (A3) de I'architecture cible d'une part, et du graphe (D3) 
de services d'autre part. 

25 

3. Procede selon la revendication 2, caracterise en ce que I'etape de 
placement (E1) comprend une etape de partition nement (P1) et une etape 
d'affectation (P2). 

30 4. Procede selon Tune des revendications precedentes, caracterise en ce 
que I'etape (E2) de preparation de la simulation comprend une etape de 
creation d'objets representant les services, ces objets etant crees par des 
objets representant les mecanismes. 
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5. Procede selon Tune des revendications precedentes, caracterise en ce 
que lors de I'etape (E3) d'execution de la simulation, des objets representant 
les services de I'architecture cible sont utilises, des attributs de ces objets 
etant mis a jour en cours de simulation en fonction de I'utilisation des 

5 ressources a I'heure simulee. 

6. Dispositif permettant de realiser une application multiprocesseur, 
caracterise en ce qu'il comprend : 

(a) un outil d'aide au placement (G1) permettant a un mappeur de placer 
10 une application decrite de maniere fonctionnelle sur une architecture 

cible ; 

(b) un modele d'architecture (A3) comprenant des modeles 
comportementaux d'elements de 1'architecture ; 

(c) un moteur de simulation (G2), utilisant le modele d'architecture, pour 
15 determiner les performances de ('application placee. 

7. Dispositif selon la revendication 6, caracterise en ce que le modele 
d'architecture (A3) comprend une interface generique, independante de 
I'architecture cible, de manidre a pouvoir etre modifie lorsque I'architecture 

20 cible est modifiee, et ce sans modifier I'outil d'aide au placement (G1) et sans 
modifier le moteur de simulation (G2). 

8. Dispositif selon la revendication 6, caracterise qu'il comprend des moyens 
de lecture de la liste des ressources (A1) de I'architecture cible d'une part, et 

25 de la liste de mecanismes et leurs definitions (A2) d'autre part. 



30 



1 er depot 



1/5 




1 er depot 



2/5 






LU 




-J 


CO 


LU 


Q 


ZD 


O 


00 







CO 

a 



37 



1 er depot 



3/5 




o^7 



=37 





LU 




UJ 




i 


CO 


CO 




—J 


ECANI 


CALCl 


PECIA 






CO 



CD 



RESSOURCE 






UNITE DE 
CALCUL 











IT) 








SE 


CO 




BUS 
SPECIALI 


ZD 
CD 





OIRE 




MEMOIRE 
SPECIALISEE 


MEM 1 





CD 

CD 






GO 

CD 



^1- 



1 er depot 



4/5 



O 

CO 



LU 

o 
> 

DC 
LU 
CO 



LU 

m 
o 



LU 
CO 
< 

o 

LU 



LU 

DC 
O 
O 
LU 

s 



CO 

O co 

rz LU 



CD 



CO 

O LU 

M 

DC ^ 

"J w 

tZ LLI 

£3Q DC 



co tr 

-=> LU 
Q 



LU 
I— 

LU 

Q 
LU 



^- J csx y co y to y S / fe / 



CD 



O 
CO 



CO 



8 



CO 



CO CO 



o 

CO 



CO 



o i— 

CM CM 



CVJ 
CM 



CM 



CO 

o 



CO 
LU 
O 

> 
DC 
LU 
CO 



c/2 Cu 

z > 

<c r> 

o o 

LU ^ 



cc o 

is 



O z 

LU CO 



111 



CO 



o 

Q _ 
CO < 



a. 



CD 



r 



22 6 

3° 



ffi LU 
LU 
£ DC 
O ^ 



LU 
Q 

CO LU 

LU r= 

o o 

^ CO 



CO IM 
W Q 

LU 
Q 



CO 



CO 



CD 



O 



s 

CD 



DC 



DC 
<C 
Q_ 



LU 
Q 

CO 



O 
I 

5 



J -^J tij ^2.J -$.J 'S-J 



m 
o 
< 



LU 
CO 

I 



CO 

LU LU 

O — 1 

DC LU 

CO DC 

co <: 

LU Q- 

CD LU 



CO 

O CO 
£Z LU 

§<! 

CD 



X LU 

m lli 



x uj 

O 

<C LU 
I— Q 



CO 
LLI 

O 



CO 
LU 
O 

DC 
I — 

o 

Z3 
Q 
O 
DC 



CO m 

O ^ 

H- UJ 

< Q 

S UJ 

DC O 

O uj 

u_ DC 



tt — ^ cvjy' coy' cD^^y' 



05 

CD 



1 er depot 



5/5 




THIS PAGE BLANK (usfto) 



■ tMtTITUT 



BREVET D'INVENTION 
CERTIFICAT D'UTILITE 

Code de la propriete intetlectuelle - Livre VI 



N° 11235*02 



iNousraiiu.1 

DtPARTEMENT DES BREVETS 

26 bts, rue de Saint Petersbourg 
75800 Paris Cedex 08 

Telephone : 01 53 04 53 04 Telecopie : 01 42 93 59 30 



DESIGNATION D'INVENTEUR(S) Page N° 

(Si le demandeur n'est pas I'inventeur ou I'unique inventeur) 



Cet imprtm6 est a remplir lisiblement a 1'encre noire 



DB U3W/260899 



Vos references pour ce dossier 

(facultatif) 



N° D'ENREGISTREMENT NATIONAL 



A r\ ^ o*fr 



TITRE DE ^INVENTION (200 caracteres ou espaces maximum) 

PROCEDE DE SIMULATION DE PERFORMANCES, ET PROCEDE DE REALISATION 
DUPLICATIONS MULTIPROCESSEURS, ET DISPOSITIFS PERMETTANT DE METTRE 
EN OEUVRE LESDITS PROCEDES. 



LE(S) DEMANDEUR(S) 



THOMSON-CSF 



DESIGNE(NT) EN TANT QU'INVENTEUR(S) : (Indiquez en haut a drohe «Page N° 1/1» S'il y a plus de trois inventeurs, 



Nom 


LENORMAND I 


Prenoms 


Eric 1 


Adresse 


Rue 


THOMSON-CSF TPI/DB 1 
1 3 , avenue du President Salvador Allende | 


Code postal et ville 


94 1 17 I ARCUEEL CEDEX 1 


Societe d'appartei 


lance (facultatif) 




Nom 




Prenoms 




Adresse 


Rue 




Code postal et ville 


1 J 


Societe d'apparte 


nance (facultatif) 




Nom 




Prenoms 




Adresse 


Rue 




Code postal et ville 




Societe d'apparte 


nance (facultatif) 




DATE ET SIGNATURE(S) 
DU (DES) DEMANDEUR(S) 
OU DU MANDATAIRE 
(Nom et qualite du signataire) 

0 5 fry. 2001 

Ivan CHAPEROT 





La loi n°78-17 du 6 janvier 1978 relative a rinformatique, aw* fichiers et aux libertes s'applique aux reponses fattes a ce formulaire. 
Elle garantit un droit d'acces et de rectification pour les donn6es vous concernant aupres de PINPI. 



IS*******" 




22850 

703-413-3000 

/0/066, (/£/C/ 

*3 



SERIAL NO. 

FILING DATE: fr^o^ S £OOQl 



